Columbia Kermit/kermit.zip/newsgroups/misc.20000824-20010305/[e-mail] _Thu Dec 28 17:12:35 2000.msg

Internet Message Format | 2020-01-01 | 4KB

Return-Path: <[e-mail]>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
    by uhaligani.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA14835
    for <[e-mail]>; Thu, 28 Dec 2000 17:12:34 -0500 (EST)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA13267
    for <[e-mail]>; Thu, 28 Dec 2000 17:12:34 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id RAA01925
    for [e-mail]; Thu, 28 Dec 2000 17:03:12 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Joe Doupnik)
Subject: Re: A wish for the FTP-client
Message-ID: <[e-mail]>
Date: 28 Dec 00 14:49:14 MDT
Organization: Utah State University
To: [e-mail]

In article <92g92f$s9j$[e-mail]>, [e-mail] (Frank da Cruz) writes:
> In article <[e-mail]>, Kevin Handy  <[e-mail]> wrote:
> : Frank da Cruz wrote:
> : > ...  How do you convert a
> : > struct tm to a time_t in a reliable way? -- i.e. without writing code to
> : > count days, months, years, leap years, leap seconds, and all the rest,
> : > taking each machine's architecture into account.  I'm sure I must have
> : > overlooked something obvious -- feel free to embarrass me.
> :
> : Under *nix, I believe the function to use is mktime
> :
> :     time_t mktime(struct tm *timeptr)
> :
> 1. The first place I looked (SunOS) doesn't have it.  However, must other
>    UNIX OS's do have it.  But...
>
> 2. Doesn't do what you want.  "In addition to computing the calendar time,
>    mktime() normalizes  the supplied tm structure" -- applies timezone
>    conversions, etc.  The problem there is, of course, we don't know, and
>    have no way to find out, the server's timezone, and even if we knew it,
>    what the rules are to convert to our own.  The struct tm is *already* in
>    GMT/UTC, and should not be converted to it again.
>
> Thus the resulting file date won't be what you want.  I think the object
> of copying the server's MDTM is so update can work in both directions.  If
> we use mktime(), I think the result will have up to 24 hours of randomness
> added or subtracted.  Am I missing something?
>
> - Frank
---------
    I face this problem daily, at 0300 during mirroring operations. As
Frank notes well, TZ material makes a mess of trying to reproduce UTC stamps
from FTP information. What I do, and what works reasonably well, is use what
FTP itself reports in a LIST command (parse according to remote server
syntax) which is what it thinks the local time/date of the file is. I then
make the client side report the same time/date at user level. This makes
local and remote systems "appear" to yield identical file listings.
    Unix plays a nasty role here were its reporting of time/date varies
with the age of the file, at least as seen in ls -l style listings. Thus
my local files are readjusted to match. The +/- one day ambiguity is just
something to live with. And how do I live with it without re-moving huge
archives? I first restamp time on files with the same name and length, and
only then consider files which differ in name and length. Yes, that is a
compromise subject to errors when the length does not change.
    The bottom line? FTP is designed to talk people to people, not machine
to machine. To do machine to machine work we invoke formal RPC style schemes,
such as NFS, NetWare, Lan Manager and so on. I think my description of source
to object is clear enough (for people). If we use FTP LIST then we can make
client and server yield the same user-level timestamps, but there will be
shifts from TZ change effects.
    Joe D.